This is part of an effort to also provide scripts to build native mingw v8.

So you would use cygwin python/ninja to build mingw v8?

@lazka Correct, I have a PR for adding V8 to vcpkg (visual c++) at microsoft/vcpkg#12687

You'll notice that depot tools is not used on that PR, I have already successfully built v8 using mingw64, but I am missing gn for a full "native" build.

The patch has merged upstream by the way 😁

Is it possible to convert this package to mingw one?

@Biswa96 It is possible, but why would you do that? ninja is msys, unless you want to redistribute gn you only need it at build time.

I have not tested whether these changes are sufficient for native mingw builds, my guess would be they are not, since there is a distinct path for Posix and Windows in the code and the code guards targeting MinGW may be stale and require more than adding some ifdefs here and there.

MinGW packages are native to Windows OS. MSYS2 and Cygwin are compatible POSIX layer. So, MSYS2 programs are somewhat slower than native one. If a package can be compiled as native one then it will be preferred. But it would be better if Windows native build is supported by upstream project.

How much slower is slower? GN is like cmake, you run it once, takes a couple of seconds and then the heavy lifting is done by ninja.

Anyway, I see your point, there is msys ninja and mingw ninja, so how about I do both?

So, mingw builds with just this patch, there's some warnings but it builds, however there seems to be a bug in mingw-w64-x86_64-ninja, for some reason the following rule deletes all input files and the static library:

rule alink_thin
command = rm -f $out && $ar rcsT $out $in
description = AR $out

seems to be a problem with the "rm -f $out" command since removing that command fixes the build. MSYS ninja does what it is supposed to do.

There is no downside about building a package both for mingw and msys. But main goal of msys2 project is to build native programs. msys2 package is required when the program relies on POSIX functions and there is no way to convert it to Windows native.

I tried to build the gn program in mingw mode but need some code changes. gn already supports Windows platform, so no significant change is required. Can you join in gitter to discuss more?

Sure, I've never use gitter before, I just joined with github so ping me there or add me to a discussion.
I am busy with other stuff right now, so I don't know how responsive I'll be for the next hours.
I created a PKGBUILD for mingw, but it failed recognising the gn.exe generated, may have to do with the install calls.
The one I created directly from the upstream repo did run, so it is not like it is a defective binary.

This is how I got it to build assuming you've cloned upstream and have a MINGW64 console already at the root of the repo:

./build/gen.py --platform=mingw
/usr/bin/ninja -C out

That would be great, most of the warnings are due to GN redefining some macros in windows_types.h so they don't have to include windows.h, other than that I saw some pointer casting warnings, these can be fixed or silenced, however the bug in native mingw ninja is what worries me most.

I don't know how to send pull request there. I follow all the steps but it does not appear in review webpage. If I send the changes can you add it there?

Sure, send me patch.

So, what else is needed on this one to get merged?

If gn works as MinGW package then this can be removed.

Since this is now part of the v8 built itself I'm closing this.

As @Biswa96 we try to keep msys packages at a minimum and prefer native builds.

If the need for this arises in the future feel free to re-open though and we can have another look.